fix(python/lorawan): declare validRange in the binding vocabulary - #90
fix(python/lorawan): declare validRange in the binding vocabulary#90reissjason wants to merge 1 commit into
Conversation
The converter emits lorav:validRange and the form JSON Schema accepts it, but the term is declared nowhere: not in ontology.ttl, not in context.jsonld, not in the README term table. A Thing Description carrying it therefore does not resolve under the published JSON-LD context, so the binding emits a term its own vocabulary does not define. Declare it in all three places, described as a plausibility range whose out-of-range values the interpreter flags. Correct two stale documents found alongside it: the package Source URL still points at the old node/python path the package was moved out of, and the note about ports layouts breaks off mid-sentence without saying to pass --fport. Signed-off-by: Jason Reiss <jreiss@multitech.com>
2b62a0d to
af4b0ec
Compare
egekorkan
left a comment
egekorkan
left a comment
There was a problem hiding this comment.
@Hao-Siemens also have a look
|
This fix makes sense. We can merge it. |
danielpeintner
left a comment
danielpeintner
left a comment
There was a problem hiding this comment.
Just a pass-by comment. I was wondering about the term itself: validRange.
Do we need "valid" at all?
We have valid enum, type etc and don't mention valid in those cases either. Isn't range enough?
Is validRange used somewhere in the LoRaWAN space?
|
@Hao-Siemens can this be also done with minimum and maximum in the level above? |
|
|
||
| [project.urls] | ||
| Source = "https://github.com/eclipse-thingweb/td-tools/tree/main/node/python/lorawan" | ||
| Source = "https://github.com/eclipse-thingweb/td-tools/tree/main/python/lorawan" |
We do not have the terms minimum and maximum defined in the lorav vocabulary. But you are refering the terms in the TD vocabulary, right? I checked the usage of this term in my local device profiles, it is raraly used. Only once in the vicki sensor from Mclimate. It is used to define [min, max] of the plausible range for the decoded value, not much relavant for decoding itself. So yes, I think we can use the minimum and maximum to represent this. And I think there will be more and more such corner cases. We need to think about to how much extend do we want to cover them and do we have existing vocabulary to present them without too much engineering work. |
|
@Hao-Siemens Minimum and Maximum are in the core TD vocabulary . See https://w3c.github.io/wot-thing-description/#numberschema or https://w3c.github.io/wot-thing-description/#property-serialization-sample I think the main problem is that all the lorawan relevant information doesn't need to be in the forms level of a TD. |
| For a `ports` layout, don't forget to pass the frame port with `--fport`, as in | ||
| the example above; without it the interpreter cannot select the right field set. |
| ``` | ||
|
|
||
| This is how to generat a bundled [device catalog](#device-catalog). | ||
| This is how the bundled [device catalog](#device-catalog) is generated. |
There was a problem hiding this comment.
danielpeintner
left a comment
danielpeintner
left a comment
There was a problem hiding this comment.
BTW, no matter what we decide with validRange, there are changes in this PR that I marked with 👍which should be merged
|
This is a good property to have in the vocabulary. As the Minimum and Maximum are in the core TD vocabulary already, we can reuse the existing vocabulary to represent this propertiy. Thus, I added them in the #96 to cover it. So I think we can skip this PR. |
AS mentioned I marked some parts of this PR with 👍 and I think those should be merged in this or another PR.... |
|
@reissjason we are not putting the valid range vocabulary in the TD level to not overlap with existing vocabularies. However, your other remarks are addressed in #96 . Closing this PR without merging |
4 participants
The converter emits lorav:validRange and the form JSON Schema accepts it, but the term is declared nowhere: not in ontology.ttl, not in context.jsonld, not in the README term table. A Thing Description carrying it therefore does not resolve under the published JSON-LD context, so the binding emits a term its own vocabulary does not define.
Declare it in all three places, described as a plausibility range whose out-of-range values the interpreter flags.
Correct two stale documents found alongside it: the package Source URL still points at the old node/python path the package was moved out of, and the note about ports layouts breaks off mid-sentence without saying to pass --fport.